Machine Type Communication (MTC) is being discussed in various wireless communication standards bodies as a new trend of wireless technology of communication network applications which typically do not require human interaction.
A broad definition of MTC is an automated communication network to and from machines. One major category of MTC devices are expected to have the characteristics of very low power consumption, very small data transmissions and a very large number of terminals. An example MTC application that fits within this category may for example be energy consumption monitoring of home appliances for smart grid systems.
In order to realize these requirements, wireless PAN (Personal Area Network: 10-20 m range) standards such as ZigBee adopt Adhoc/Mesh topology where there is no central coordinating entity to control the traffic flow, and where the scheduling/routing of data transmission is managed in a distributed manner. The Mesh characteristics allow data to be conveyed beyond the PAN range by multihopping the information via a series of neighbouring devices. Because each transmission link is kept short, the power consumption per terminal is kept low.
However, in order to reliably convey information from a source to a destination, this topology encounters several problems.
Routing/Scheduling Complexity
One characteristic of Mesh topology is that there could be multiple routes from source to destination. FIG. 1 schematically illustrates a Mesh network topology. Seven terminal devices A to G are shown. In order to transfer information from terminal A to terminal G, route 1 (solid arrows) or route 2 (dashed arrows) can be taken. The arrows accompanied by question marks indicate alternative routes available for transmission from a given terminal. In particular, terminal A needs to make a decision whether to transmit its data first to terminal B (via solid arrow), or to terminal C (via dashed arrow). Terminal D needs to make a similar decision. This means that each terminal in a Mesh topology requires knowledge of the existing surrounding terminals and requires the capability to select the optimum route to a given destination, which intuitively requires significant intelligence.
Furthermore, in an energy conserving system, some terminals may be required to switch into a hibernation mode when they are not required to receive or transmit. In such a scenario, because there is no central coordinator, each terminal is required to have knowledge of when the neighbouring terminals are capable to receive information, which would impact on how they schedule transmission.
Hidden Node Problem
As described above, in a Mesh topology each terminal is required to make a decision on when to transmit data. FIG. 2 schematically illustrates how this can be problematic due to hidden nodes. In FIG. 2, four terminals A to D are shown, with the radio transmission range of terminals A and C being indicated by the circles surrounding these respective terminals. In the deployment scenario envisaged in FIG. 2, where terminal A has data to send to terminal B, and terminal C has data to send to terminal D, because terminal A is not in range of C and vice versa, there is possibility that terminals A and C may commence transmission at the same time. In this situation, a mixed signal from terminals A and C will be received at terminal B, which may inhibit decoding of the desired signal (from terminal A) at terminal B. A “listen before send” mechanism at the transmitting terminals (to observer for interfering transmissions) will not work in this case because the transmitting terminals are out of range of each other, or in other words are hidden from each other. Complex mechanisms would be required to effectively solve this hidden node problem.
Excessive Use of Resource (Medium & Energy)
The nature of the Mesh topology requires the same data to be transmitted multiple times through multiple hops. FIGS. 3A and 3B schematically illustrate how control signals are communicated from a terminal A to a terminal G, and how in response data signals are communicated from the terminal G to the terminal A. In particular, FIG. 3A illustrates a single hop scenario whereas FIG. 3B illustrates a multi-hop scenario. In FIG. 3A, the terminals A and G communicate directly with each other. Neighbouring (intermediate) terminals B, D and E are not utilised in the communication. More specifically, the terminal A sends a control signal directly to the terminal G to request data, and the terminal G responsively transmits the requested data directly back to the terminal A. The period between the transmission of the control signal from the terminal A to the reception of the data at the terminal A is referred to as the transmission time. In contrast, in FIG. 3B, the terminals A and G communicate with each other via the terminals B, D and E, in a multi-hop manner. More specifically, the terminal A sends a control signal to request data firstly to the terminal B. Terminal B then relays the control signal to the terminal D, and so on through the terminal E until the control signal is finally received at the terminal G from the terminal E. The terminal G then responsively transmits the requested data firstly to the terminal E, where it is relayed on to the terminal D and so on through the terminal B until the data is finally received at the terminal A. As with FIG. 3A, the period between the transmission of the control signal from the terminal A to the reception of the data at the terminal A is referred to as the transmission time.
As can be understood from a comparison of FIGS. 3A and 3B, not only does multi-hopping increase the latency to transfer information from source to destination, but it also has some additional side effects. One effect is, since the same data needs to be sent multiple times, it consumes more medium time than when transmitted in a single hop. Routing signals and traffic flow control signals may also be sent multiple times, making the effect more serious. This problem is particularly significant in MTC where there may be large numbers of terminals, and for which the signalling information (control signals) is likely to dominate the actual information (data) transmitted.
Also, because in a Mesh topology terminals within the route (terminals B, D & E in FIG. 3B) need to receive and transmit data and signalling that is not originated by itself, they are required to consume more energy than in a single hop network, in which they would only transmit self-originated data. These same problems (excessive use of medium) can be observed in a Relay topology or when a gateway is used.
Accordingly, it will be understood that one of the main characteristics of MTC is that terminals are expected to have extremely low power consumption. One effective way to realize this is to limit the transmission range of the MTC terminals, and to use Relay or Mesh topology to multihop the information from the MTC terminals to the base station.
However, it will also be understood from the above discussion that Relay and Mesh topologies have their own drawbacks in that each relay or mesh terminal needs to have distributed scheduling and routing capability in order to convey information in a multihop manner, which brings complexity to these terminals. Furthermore, the scheduling messages need also to be multihopped, which results in an ineffective use of the medium.
An uplink only single-hop relay is described in US2008/0285499. The mobile terminal in this case is agnostic to the relay node, that is it is not aware that its uplink data is being forwarded by the relay node. One characteristic of this transparent operation is that the relay node only transmits towards the base station (eNB), and never to the mobile terminal (UE). This creates some problems. For example, this arrangement will not work with a Type 1 relay of the sort that is being standardized in 3GPP. Additionally, there is no way to enforce per link automatic repeat requests (ARQ). There is no way to compensate for additional uplink delay caused by two or more hops. Also, there is no way to measure downlink channel quality between individual multihop links.